開放安全模型使用指南
背景：現代信任與安全領域中的開放 AI 模型
現代信任與安全（T&S）團隊需要處理 DIRE framework 所列出的四種功能原型。
- Detection（偵測）：透過行為 Signal 與既有資料庫，找出帳號、行為及內容中的潛在風險。例如雜湊比對會依數位指紋識別已知威脅。這個階段用來判斷是否發生問題。
- Investigation（調查）：評估個別實體以外的脈絡，以分析廣泛的攻擊模式，或深入調查單一事件。這個階段用來理解問題為何發生。
- Review（審查）：依政策評估內容，以決定適當的後續步驟。這個階段用來在複雜案例中判斷最佳處理方式。
- Enforcement（執行）：採取措施並履行通報義務。這個階段用來將威脅從平台移除。
針對安全用途微調的 AI 模型可以支援四個面向，但最適合 Detection 與 Review。過去市面上已有許多偵測工具，但既有工具主要在兩方面不足。第一，往往高度依賴人工處理或使用者檢舉。第二，工具分散於不同內部系統與供應商，難以整合。
我們將開放安全模型定義為可免費取得、不受特定平台限制而能部署，且專門針對信任與安全用途微調的模型。詳情可參閱 ROOST Model Community（RMC）README。這類模型可回應上述兩項歷史問題。例如，規模較小的開發團隊可能沒有資源執行高階私有模型；處理敏感個人識別資訊的團隊可能希望資料留在自己的環境；許多團隊也可能想採用自己的政策，或依政策進一步微調特定模型。
AI 能力超越傳統分類器後，相關使用情境持續增加。但進展也迅速帶來新的網路安全威脅，從新型 AI 生成兒童性虐待材料（CSAM）到 agentic scam。為了因應這些威脅，學習如何使用安全模型將愈來愈重要。本指南希望協助新的採用者展開學習。
在信任與安全架構中使用開放模型
現代開放模型在信任與安全情境中常見三種用途，但下列內容並非完整清單。
- 內容偵測：依既有政策使用模型分類內容。這是分類器長期以來的典型用途，通常產生二元判斷，例如「違反政策」或「可接受」。
- 調查與審查支援：使用模型支援自動或人工的調查及審查作業。具推理能力的模型尤其能處理抽象或依模式比對的威脅。
- 案例：Phoebe 是一套 agentic 解決方案，可分析威脅模式，再透過 ROOST Osprey 引擎建議阻止威脅的新規則，以加速完整調查流程。
- 持續改進：使用模型反覆改進既有政策與流程，特別適合建立能同時被人工安全團隊與 AI 理解的政策。
- 案例：Open Safeguard Hackathon 參與者建立了 Policy Agent CLI，用來測試、改進並反覆調整特定政策的表現。
這三種用途經過簡化，彼此也不互斥，實際上往往相互交會。例如，愈來愈多平台考慮採用兩階段安全模型。第一個模型通常較小、延遲較低，作為第一層防線，判斷容易分類的案例。有不確定性的邊界案例再轉交第二個模型，通常是效能較高且具推理能力的模型，由它提出建議措施供人工審查。這些決定產生的資料則可以，也應該，用來持續改進政策。
更重要的是，以上用途只呈現開放安全模型能力的一部分。能力較新的模型可能讓信任與安全團隊自動處理更複雜的工作，例如將內容分群以深入調查、解析多輪對話中的隱藏威脅，例如誘騙，或採用 agentic moderator。平台規模擴大時，這些進階用途特別有價值，可協助執行帳號層級評估及更廣泛的安全工作，例如主動阻止詐騙活動。
選擇模型：開放模型與封閉模型
工具選擇幾乎沒有適用所有情境的單一答案，在這個細緻複雜的領域尤其如此。應依需求選擇最合適的工具，同時理解各種模型選擇在效能、延遲、價格等面向的主要取捨。不同模型各有優勢。有些工作可受益於推理能力，另一些工作只需要最快、成本最低的解決方案。
選擇模型時，一項重要考量是採用開放模型或封閉模型。以下是兩者取捨的簡化摘要。
開放模型通常提供以下優點
- 可高度自訂及微調，以回應特定政策或脈絡問題
- 可控制資料、內容及成本結構，在處理具有法遵要求的敏感資訊時尤其重要
封閉模型通常提供以下優點
- 涵蓋較多模型規模與能力，從大型前沿模型到較小的專用模型
- 可使用既有整合，設定通常較容易，例如透過 Coop 使用 Google Content Safety API 或 OpenAI Moderation API
這項區分並未涵蓋眾多提供高品質安全導向模型的專業供應商，其中部分模型最初也是以開放模型為基礎。多個模型可以用在信任與安全技術堆疊的不同階段，因此混合使用封閉與開放模型也可能有效。
具體提示與技巧
開始使用：執行開放模型的逐步指南
- 決定使用哪一個模型。 應納入模型授權是否存在無法接受的限制、模型規模及延遲是否足夠，以及模型表現等考量。表現通常可從 model card 或評估結果了解。
- 決定在本機執行模型或使用託管推論 API。 本機模型可完整控制資料隱私及設定，API 通常較容易設定。
- 這項選擇也影響延遲等考量。例如，在沒有雲端 GPU 的 Mac 本機執行模型，速度可能比使用推論服務供應商或配置 GPU 更慢。
- 部署前測試並改進模型。 部署前應確認模型在您的政策上具有足夠表現。可考慮以下做法。
- 使用或建立結構化、高品質的「黃金」資料集，用來比較模型表現。這項工作可能耗費時間與成本，可詢問 RMC 同儕是否有可分享的資料集。
- 找出最在意的評估指標，例如 precision 或 recall。
- 了解錯誤來自模型表現或政策不一致。
- 若成本與時間允許，可考慮進一步微調。現成分類器並未依您的特定政策自訂，缺少額外微調時，表現未必符合需求。
在意成本的開發者，可先在信任與安全工作流程使用較小、較輕量的模型。許多基本且量大的工作可由小型模型快速有效地完成。應評估哪些環節確實需要更大、更複雜的模型。在投入完整部署前，先以資料樣本批次驗證候選模型，再依結果調整方法。
其他考量
政策說明
良好政策是有效部署開放安全模型的必要條件。雖然「良好政策」沒有唯一答案，即使模型使用方式在技術上完全正確，不合適的政策仍會導致不理想的結果。ROOST 不負責撰寫政策，但 RMC 已開源以下範例。
延伸閱讀
本文並非完整摘要。如要進一步了解，可參閱以下資源。
- Musubi：How to use LLMs for Content Moderation
- ROOST：Building Safety Infrastructure in the Open
- Hugging Face：State of Open Source on Hugging Face: Spring 2026
採用前仍須以自己的政策、資料、語言及威脅情境評估模型。第一輪翻譯不構成模型選擇、法遵或自動處置建議。